|
|
In article <3a025559$1@news.povray.org>, "Mark Wagner"
<mar### [at] gtenet> wrote:
> >I am going to make a post_process filter which uses a spline to adjust
> >color values...is this what you are talking about?
> Yes.
I will send you the code as soon as it is tested.
> >You mean it picks a random pixel each time? Another thing that might be
> >nice: some kind of "progressive" antialiasing, that renders the image
> >without antialiasing and then makes several "refinement" passes.
> That's going to be part of the system, since I can't do antialiasing with
> just one pixel.
Good. :-)
> I don't have it implemented yet, but this will be for the "poly"
> object type. It's much easier to enter a formula for a 7th-order
> polynomial as a formula than as a string of a hundred coefficients.
Oh, I thought this was for something else...this seems rather redundant,
since you can just use isosurfaces to do the same thing, and
often(usually?) with faster rendering.
> >I would suggest using one of the spline patches...less duplicate code,
> >more standardized, etc...
>
> This is going to be an improvement on the spline{} syntax.
Oh...
Ok, what improvements are you thinking of? More spline types, the
ability to choose what kind of spline to use at evaluation time?
By the second, I mean something like this:
#declare Spline = spline {...the usual spline stuff...}
#declare Val1 = Spline(XVal);
#declare Val2 = Spline(XVal, cubic_spline);
#declare Val3 = Spline(XVal, linear_spline);
Another wild idea that might be useful: allow splines to be used as
color maps. :-)
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|